
<!DOCTYPE html>

<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

    <title>Glossary of terms &#8212; LAVA 2024.05 documentation</title>
    <link rel="stylesheet" type="text/css" href="_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="_static/bootstrap-sphinx.css" />
    <script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
    <script src="_static/jquery.js"></script>
    <script src="_static/underscore.js"></script>
    <script src="_static/_sphinx_javascript_frameworks_compat.js"></script>
    <script src="_static/doctools.js"></script>
    <script src="_static/sphinx_highlight.js"></script>
    <link rel="shortcut icon" href="_static/favicon.ico"/>
    <link rel="index" title="Index" href="genindex.html" />
    <link rel="search" title="Search" href="search.html" />
    <link rel="next" title="Getting support" href="support.html" />
    <link rel="prev" title="Contents" href="contents.html" />
    <link rel="canonical" href="https://docs.lavasoftware.org/lava/glossary.html" />
  
<meta charset='utf-8'>
<meta http-equiv='X-UA-Compatible' content='IE=edge,chrome=1'>
<meta name='viewport' content='width=device-width, initial-scale=1.0, maximum-scale=1'>
<meta name="apple-mobile-web-app-capable" content="yes">
<script type="text/javascript" src="_static/js/jquery-1.12.4.min.js"></script>
<script type="text/javascript" src="_static/js/jquery-fix.js"></script>
<script type="text/javascript" src="_static/bootstrap-3.4.1/js/bootstrap.min.js"></script>
<script type="text/javascript" src="_static/bootstrap-sphinx.js"></script>


  </head><body>

  <div id="navbar" class="navbar navbar-default navbar-fixed-top">
    <div class="container">
      <div class="navbar-header">
        <!-- .btn-navbar is used as the toggle for collapsed navbar content -->
        <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".nav-collapse">
          <span class="icon-bar"></span>
          <span class="icon-bar"></span>
          <span class="icon-bar"></span>
        </button>
        <a class="navbar-brand" href="index.html"><span><img src="_static/lava.png"></span>
          LAVA</a>
        <span class="navbar-text navbar-version pull-left"><b>2024.05</b></span>
      </div>

        <div class="collapse navbar-collapse nav-collapse">
          <ul class="nav navbar-nav">
            
                <li><a href="genindex.html">Index</a></li>
                <li><a href="contents.html">Contents</a></li>
            
            
              <li class="dropdown globaltoc-container">
  <a role="button"
     id="dLabelGlobalToc"
     data-toggle="dropdown"
     data-target="#"
     href="index.html">Site <b class="caret"></b></a>
  <ul class="dropdown-menu globaltoc"
      role="menu"
      aria-labelledby="dLabelGlobalToc"><ul class="current">
<li class="toctree-l1"><a class="reference internal" href="index.html">Introduction to LAVA</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="contents.html">Contents</a></li>
</ul>
<ul class="current">
<li class="toctree-l1 current"><a class="current reference internal" href="#">Glossary of terms</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="support.html">Getting support</a></li>
</ul>
</ul>
</li>
              
                <li class="dropdown">
  <a role="button"
     id="dLabelLocalToc"
     data-toggle="dropdown"
     data-target="#"
     href="#">Page <b class="caret"></b></a>
  <ul class="dropdown-menu localtoc"
      role="menu"
      aria-labelledby="dLabelLocalToc"><ul>
<li><a class="reference internal" href="#">Glossary of terms</a></li>
</ul>
</ul>
</li>
              
            
            
              
                
  <li>
    <a href="contents.html" title="Previous Chapter: Contents"><span class="glyphicon glyphicon-chevron-left visible-sm"></span><span class="hidden-sm hidden-tablet">&laquo; Contents</span>
    </a>
  </li>
  <li>
    <a href="support.html" title="Next Chapter: Getting support"><span class="glyphicon glyphicon-chevron-right visible-sm"></span><span class="hidden-sm hidden-tablet">Getting support &raquo;</span>
    </a>
  </li>
              
            
            
            
            
              <li class="hidden-sm"></li>
            
          </ul>

          
            
<form class="navbar-form navbar-right" action="search.html" method="get">
 <div class="form-group">
  <input type="text" name="q" class="form-control" placeholder="Search" />
 </div>
  <input type="hidden" name="check_keywords" value="yes" />
  <input type="hidden" name="area" value="default" />
</form>
          
        </div>
    </div>
  </div>

<div class="container">
  <div class="row">
    <div class="body col-md-12 content" role="main">
      
  <section id="glossary-of-terms">
<span id="glossary"></span><span id="index-0"></span><h1>Glossary of terms<a class="headerlink" href="#glossary-of-terms" title="Permalink to this heading">¶</a></h1>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="naming-conventions.html#naming-conventions"><span class="std std-ref">Naming conventions and LAVA architecture</span></a></p>
</div>
<p><strong>A</strong> [ <a class="reference internal" href="#term-action-level"><span class="xref std std-term">action level</span></a> ] [ <a class="reference internal" href="#term-alias"><span class="xref std std-term">alias</span></a> ]</p>
<p><strong>B</strong> [ <a class="reference internal" href="#term-BMC"><span class="xref std std-term">BMC</span></a> ]</p>
<p><strong>C</strong> [ <a class="reference internal" href="#term-chart"><span class="xref std std-term">chart</span></a> ] [ <a class="reference internal" href="#term-ci-loop"><span class="xref std std-term">ci loop</span></a> ]</p>
<p><strong>D</strong> [ <a class="reference internal" href="#term-device"><span class="xref std std-term">device</span></a> ] [ <a class="reference internal" href="#term-device-dictionary"><span class="xref std std-term">device dictionary</span></a> ]
[<a class="reference internal" href="#term-device-status-transition"><span class="xref std std-term">device status transition</span></a> ]
[ <a class="reference internal" href="#term-device-tag"><span class="xref std std-term">device tag</span></a> ] [ <a class="reference internal" href="#term-device-type"><span class="xref std std-term">device type</span></a> ] [ <a class="reference internal" href="#term-developer-image"><span class="xref std std-term">developer image</span></a> ]
[ <a class="reference internal" href="#term-dispatcher"><span class="xref std std-term">dispatcher</span></a> ] [ <a class="reference internal" href="#term-distributed-deployment"><span class="xref std std-term">distributed deployment</span></a> ] [ <a class="reference internal" href="#term-DTB"><span class="xref std std-term">DTB</span></a> ]
[ <a class="reference internal" href="#term-DUT"><span class="xref std std-term">DUT</span></a> ]</p>
<p><strong>F</strong> [ <a class="reference internal" href="#term-frontend"><span class="xref std std-term">frontend</span></a> ]</p>
<p><strong>G</strong> [ <a class="reference internal" href="#term-group"><span class="xref std std-term">group</span></a> ]</p>
<p><strong>H</strong> [ <a class="reference internal" href="#term-hacking-session"><span class="xref std std-term">hacking session</span></a> ] [ <a class="reference internal" href="#term-health-check"><span class="xref std std-term">health check</span></a> ]
[<a class="reference internal" href="#term-hidden-device-type"><span class="xref std std-term">hidden device type</span></a> ] [ <a class="reference internal" href="#term-hostname"><span class="xref std std-term">hostname</span></a> ]</p>
<p><strong>I</strong> [ <a class="reference internal" href="#term-inline"><span class="xref std std-term">inline</span></a> ] [ <a class="reference internal" href="#term-interface-tag"><span class="xref std std-term">interface tag</span></a> ]</p>
<p><strong>J</strong> [ <a class="reference internal" href="#term-jinja2"><span class="xref std std-term">jinja2</span></a> ] [ <a class="reference internal" href="#term-job-context"><span class="xref std std-term">job context</span></a> ] [ <a class="reference internal" href="#term-job-definition"><span class="xref std std-term">job definition</span></a> ]</p>
<p><strong>L</strong> [ <a class="reference internal" href="#term-LAVA_LXC_HOME"><span class="xref std std-term">LAVA_LXC_HOME</span></a> ] [ <a class="reference internal" href="#term-LXC"><span class="xref std std-term">LXC</span></a> ] [ <a class="reference internal" href="#term-lxc"><span class="xref std std-term">lxc://</span></a> ]</p>
<p><strong>M</strong> [ <a class="reference internal" href="#term-messageID"><span class="xref std std-term">messageID</span></a> ] [ <a class="reference internal" href="#term-metadata"><span class="xref std std-term">metadata</span></a> ] [ <a class="reference internal" href="#term-MultiNode"><span class="xref std std-term">MultiNode</span></a> ]</p>
<p><strong>N</strong> [ <a class="reference internal" href="#term-namespace"><span class="xref std std-term">namespace</span></a> ]</p>
<p><strong>O</strong> [ <a class="reference internal" href="#term-offline"><span class="xref std std-term">offline</span></a> ]</p>
<p><strong>P</strong> [ <a class="reference internal" href="#term-parameters"><span class="xref std std-term">parameters</span></a> ] [ <a class="reference internal" href="#term-PDU"><span class="xref std std-term">PDU</span></a> ] [ <a class="reference internal" href="#term-physical-access"><span class="xref std std-term">physical access</span></a> ]
[ <a class="reference internal" href="#term-pipeline"><span class="xref std std-term">pipeline</span></a> ] [ <a class="reference internal" href="#term-priority"><span class="xref std std-term">priority</span></a> ] [ <a class="reference internal" href="#term-production-image"><span class="xref std std-term">production image</span></a> ]
[ <a class="reference internal" href="#term-prompts"><span class="xref std std-term">prompts</span></a> ] [ <a class="reference internal" href="#term-protocol"><span class="xref std std-term">protocol</span></a> ]</p>
<p><strong>Q</strong> [ <a class="reference internal" href="#term-query"><span class="xref std std-term">query</span></a> ]</p>
<p><strong>R</strong> [ <a class="reference internal" href="#term-refactoring"><span class="xref std std-term">refactoring</span></a> ]
[ <a class="reference internal" href="#term-remote-worker"><span class="xref std std-term">remote worker</span></a>]
[ <a class="reference internal" href="#term-restricted-device"><span class="xref std std-term">restricted device</span></a> ]
[ <a class="reference internal" href="#term-results"><span class="xref std std-term">results</span></a> ]
[ <a class="reference internal" href="#term-retired"><span class="xref std std-term">retired</span></a> ]
[ <a class="reference internal" href="#term-role"><span class="xref std std-term">role</span></a> ] [ <a class="reference internal" href="#term-rootfs"><span class="xref std std-term">rootfs</span></a> ] [ <a class="reference internal" href="#term-rootfstype"><span class="xref std std-term">rootfstype</span></a> ]</p>
<p><strong>S</strong> [ <a class="reference internal" href="#term-scheduler"><span class="xref std std-term">scheduler</span></a> ]</p>
<p><strong>T</strong> [ <a class="reference internal" href="#term-target_group"><span class="xref std std-term">target_group</span></a> ] [ <a class="reference internal" href="#term-test-run"><span class="xref std std-term">test run</span></a> ] [ <a class="reference internal" href="#term-test-shell"><span class="xref std std-term">test shell</span></a> ]
[ <a class="reference internal" href="#term-test-suite"><span class="xref std std-term">test suite</span></a> ] [ <a class="reference internal" href="#term-tftp"><span class="xref std std-term">tftp</span></a> ] [ <a class="reference internal" href="#term-token"><span class="xref std std-term">token</span></a> ]</p>
<p><strong>U</strong> [ <a class="reference internal" href="#term-UART"><span class="xref std std-term">UART</span></a> ]</p>
<p><strong>V</strong> [ <a class="reference internal" href="#term-visibility"><span class="xref std std-term">visibility</span></a>] [ <a class="reference internal" href="#term-VLANd"><span class="xref std std-term">VLANd</span></a> ]</p>
<p><strong>W</strong> [ <a class="reference internal" href="#term-worker"><span class="xref std std-term">worker</span></a> ]</p>
<dl class="glossary">
<dt id="term-action-level">action level<a class="headerlink" href="#term-action-level" title="Permalink to this term">¶</a></dt><dd><p>The <a class="reference internal" href="#term-pipeline"><span class="xref std std-term">pipeline</span></a> is organized into sections and levels. The first
section of the pipeline is given level 1. Sub tasks of that section start
with level 1.1 and so on. Log files and job definitions will refer to
actions using the level. Details of the action can then be accessed using
the level as the location: <code class="docutils literal notranslate"><span class="pre">job/8360/definition#2.4.5</span></code></p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="dispatcher-design.html#pipeline-construction"><span class="std std-ref">Pipeline construction and flow</span></a></p>
</div>
</dd>
<dt id="term-alias">alias<a class="headerlink" href="#term-alias" title="Permalink to this term">¶</a></dt><dd><p>A string which can be used to relate the descriptive device-type name to a
particular list of aliases which could be used to lookup the matching
device-type. This can be useful to list the <a class="reference internal" href="#term-DTB"><span class="xref std std-term">device tree blobs</span></a>
which can be used with this device-type. (Aliases can be used in job
submissions directly.)</p>
</dd>
<dt id="term-BMC">BMC<a class="headerlink" href="#term-BMC" title="Permalink to this term">¶</a></dt><dd><p>A Baseboard Management Controller (BMC) is an embedded controller
on a computer mainboard which allows external monitoring and
management of the computer system.</p>
</dd>
<dt id="term-chart">chart<a class="headerlink" href="#term-chart" title="Permalink to this term">¶</a></dt><dd><p>A chart allows users to track <a class="reference internal" href="#term-results"><span class="xref std std-term">results</span></a> over time using
<a class="reference internal" href="#term-query"><span class="xref std std-term">queries</span></a>.</p>
</dd>
<dt id="term-ci-loop">ci loop<a class="headerlink" href="#term-ci-loop" title="Permalink to this term">¶</a></dt><dd><p>Continuous Integration (CI) typically involves repeated automated
submissions using automated builds of the artifacts prompted by
modifications made by developers. Providing feedback to the developers on
whether the automated build passed or failed creates a loop. LAVA is
designed as one component of a ci loop.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="custom-result-handling.html#ci-loop"><span class="std std-ref">Closing the CI loop</span></a>, <a class="reference internal" href="lava_ci.html#continuous-integration"><span class="std std-ref">Continuous Integration</span></a> and
<a class="reference internal" href="#term-metadata"><span class="xref std std-term">metadata</span></a></p>
</div>
</dd>
<dt id="term-device">device<a class="headerlink" href="#term-device" title="Permalink to this term">¶</a></dt><dd><p>A device in LAVA is an instance of a <a class="reference internal" href="#term-device-type"><span class="xref std std-term">device type</span></a>.</p>
<ul class="simple">
<li><p>Test writers: see <a class="reference internal" href="#term-device-tag"><span class="xref std std-term">device tag</span></a></p></li>
<li><p>Admins: see <a class="reference internal" href="first-devices.html#create-device-database"><span class="std std-ref">Create a device in the database</span></a> and <a class="reference internal" href="#term-device-dictionary"><span class="xref std std-term">device dictionary</span></a>.</p></li>
<li><p>Developers: see <a class="reference internal" href="naming-conventions.html#naming-conventions"><span class="std std-ref">Naming conventions and LAVA architecture</span></a></p></li>
</ul>
</dd>
<dt id="term-device-dictionary">device dictionary<a class="headerlink" href="#term-device-dictionary" title="Permalink to this term">¶</a></dt><dd><p>The device dictionary holds data which is specific to one device within a
group of devices of the same device type. For example, the power control
commands which reference a single port number. The dictionary itself is a
key:value store within the LAVA server database which admins can modify to
set configuration values according to the <a class="reference internal" href="#term-pipeline"><span class="xref std std-term">pipeline</span></a> design.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="lava-scheduler-device-dictionary.html#device-dictionary-help"><span class="std std-ref">Detailed device dictionary information in LAVA Scheduler</span></a>,
<a class="reference internal" href="pipeline-admin.html#create-device-dictionary"><span class="std std-ref">Creating a device dictionary for the device</span></a>, <a class="reference internal" href="connections.html#configuring-serial-ports"><span class="std std-ref">Configuring serial ports</span></a>
and <a class="reference internal" href="pipeline-admin.html#viewing-device-dictionary-content"><span class="std std-ref">Viewing current device dictionary content</span></a>.</p>
</div>
</dd>
<dt id="term-device-status-transition">device status transition<a class="headerlink" href="#term-device-status-transition" title="Permalink to this term">¶</a></dt><dd><p>A record of when a device changed <a class="reference internal" href="lava-scheduler-device-help.html#device-status"><span class="std std-ref">Device state</span></a>, who caused the
transition, when the transition took place as well as any message assigned
to the transition. Individual transitions can be viewed in LAVA at
<code class="docutils literal notranslate"><span class="pre">&lt;server&gt;scheduler/transition/&lt;ID&gt;</span></code> where the ID is a sequential integer.
If the transition was caused by a job, this view will link to that job.</p>
</dd>
<dt id="term-device-tag">device tag<a class="headerlink" href="#term-device-tag" title="Permalink to this term">¶</a></dt><dd><p>A tag is a device specific label which describes specific hardware
capabilities of this specific device. Test jobs using tags will fail if no
suitable devices exist matching the requested device tag or tags. Tags are
typically used when only a proportion of the devices of the specified type
have hardware support for a particular feature, possibly because those
devices have peripheral hardware connected or enabled. A device tag can
only be created or assigned to a particular device by a lab admin. When
requesting tags, remember to include a description of what the tagged
device can provide to a Test Job.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="developing-tests.html#device-tags-example"><span class="std std-ref">Using device tags</span></a></p>
</div>
</dd>
<dt id="term-device-type">device type<a class="headerlink" href="#term-device-type" title="Permalink to this term">¶</a></dt><dd><p>The common type of a number of devices in LAVA. The device type may have a
<a class="reference internal" href="#term-health-check"><span class="xref std std-term">health check</span></a> defined. Devices with the same device type will run
the same health check at regular intervals. See <a class="reference internal" href="devicetypes.html#device-types"><span class="std std-ref">Device types</span></a>.</p>
</dd>
<dt id="term-developer-image">developer image<a class="headerlink" href="#term-developer-image" title="Permalink to this term">¶</a></dt><dd><p>A build of Android which, when deployed to a device, means that the device
<strong>is visible</strong> to <code class="docutils literal notranslate"><span class="pre">adb</span></code>. Devices configured this way will be able to have
the image replaced using any machine, just be connecting a suitable cable,
so these images are not typically deployed onto hardware which will be sold
to the customer without having this image replaced with a production image.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="deploy-lxc.html#lava-lxc-protocol-android"><span class="std std-ref">Using the LXC protocol to support Android</span></a></p>
</div>
</dd>
<dt id="term-dispatcher">dispatcher<a class="headerlink" href="#term-dispatcher" title="Permalink to this term">¶</a></dt><dd><p>A machine to which multiple devices are connected. The dispatcher has
<code class="docutils literal notranslate"><span class="pre">lava-dispatcher</span></code> installed and passes the commands to the device and
other processes involved in running the LAVA test. A dispatcher does not
need to be at the same location as the server which runs the scheduler. The
term <code class="docutils literal notranslate"><span class="pre">dispatcher</span></code> relates to how the machine operates the
<code class="docutils literal notranslate"><span class="pre">lava-dispatch</span></code> process using <code class="docutils literal notranslate"><span class="pre">lava-worker</span></code>. The related term
<a class="reference internal" href="#term-worker"><span class="xref std std-term">worker</span></a> relates to how the machine appears from the server.</p>
</dd>
<dt id="term-distributed-deployment">distributed deployment<a class="headerlink" href="#term-distributed-deployment" title="Permalink to this term">¶</a></dt><dd><p>A method of installing LAVA involving a single server and one or
more <a class="reference internal" href="#term-remote-worker"><span class="xref std std-term">remote workers</span></a> which communicate with the
master using HTTP. This method spreads the load of running tests on
devices multiple dispatchers.</p>
</dd>
<dt id="term-DTB">DTB<a class="headerlink" href="#term-DTB" title="Permalink to this term">¶</a></dt><dd><p>Device Tree Blob - file describing hardware configuration,
commonly used on ARM devices with the Linux kernel. See
<a class="reference external" href="https://en.wikipedia.org/wiki/Device_tree">https://en.wikipedia.org/wiki/Device_tree</a> for more information.</p>
</dd>
<dt id="term-DUT">DUT<a class="headerlink" href="#term-DUT" title="Permalink to this term">¶</a></dt><dd><p>Device Under Test - a quick way to refer to the <a class="reference internal" href="#term-device"><span class="xref std std-term">device</span></a> in LAVA.</p>
</dd>
<dt id="term-frontend">frontend<a class="headerlink" href="#term-frontend" title="Permalink to this term">¶</a></dt><dd><p><code class="docutils literal notranslate"><span class="pre">lava-server</span></code> provides a generic <cite>frontend</cite> consisting of the Results,
Queries, Job tables, Device tables and Charts. Many projects will need to
customize this data to make it directly relevant to the developers. This is
supported using the <a class="reference internal" href="data-export.html#xml-rpc"><span class="std std-ref">XML-RPC</span></a> and REST API support.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="index.html#what-is-lava-not"><span class="std std-ref">What is LAVA not?</span></a> and <a class="reference internal" href="custom-result-handling.html#custom-result-handling"><span class="std std-ref">Custom result handling</span></a>.</p>
</div>
</dd>
<dt id="term-group">group<a class="headerlink" href="#term-group" title="Permalink to this term">¶</a></dt><dd><p>LAVA uses the Django local group configuration (synchronizing
Django groups with external groups like LDAP is <strong>not</strong> supported).
Users can be added to groups after the specified group has been
created by admins using the <a class="reference internal" href="first-devices.html#django-admin-interface"><span class="std std-ref">Django administration interface</span></a> or the
<code class="docutils literal notranslate"><span class="pre">lava-server</span> <span class="pre">manage</span> <span class="pre">groups</span></code> and <code class="docutils literal notranslate"><span class="pre">lava-server</span> <span class="pre">manage</span> <span class="pre">users</span></code>
command line support.</p>
</dd>
<dt id="term-hacking-session">hacking session<a class="headerlink" href="#term-hacking-session" title="Permalink to this term">¶</a></dt><dd><p>A test job which uses a particular type of test definition to allow users
to connect to a test device and interact with the test environment
directly. Normally implemented by installing and enabling an SSH daemon
inside the test image. Not all devices can support hacking sessions.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="hacking-session.html#hacking-session"><span class="std std-ref">LAVA Hacking Sessions</span></a>.</p>
</div>
</dd>
<dt id="term-health-check">health check<a class="headerlink" href="#term-health-check" title="Permalink to this term">¶</a></dt><dd><p>A test job for one specific <a class="reference internal" href="#term-device-type"><span class="xref std std-term">device type</span></a> which is automatically run
at regular intervals to ensure that the physical device is capable of
performing the minimum range of tasks. If the health check fails on a
particular device, LAVA will automatically put that device <a class="reference internal" href="#term-offline"><span class="xref std std-term">offline</span></a>.
Health checks have higher <a class="reference internal" href="#term-priority"><span class="xref std std-term">priority</span></a> than any other jobs.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="healthchecks.html#health-checks"><span class="std std-ref">Writing Health Checks for devices</span></a>.</p>
</div>
</dd>
<dt id="term-hidden-device-type">hidden device type<a class="headerlink" href="#term-hidden-device-type" title="Permalink to this term">¶</a></dt><dd><p>A device type can be hidden by the LAVA administrators. Devices of a
<a class="reference internal" href="hiddentypes.html#v2-hidden-device-type"><span class="std std-ref">Hidden device types</span></a> will only be visible to owners of at least
once device of this type. Other users will not be able to access the job
output, device status transition pages or bundle streams of devices of a
hidden type. Devices of a hidden type will be shown as <code class="docutils literal notranslate"><span class="pre">Unavailable</span></code> in
tables of test jobs and omitted from tables of devices and device types if
the user viewing the table does not own any devices of the hidden type.</p>
</dd>
<dt id="term-hostname">hostname<a class="headerlink" href="#term-hostname" title="Permalink to this term">¶</a></dt><dd><p>The unique name of this device in this LAVA instance, used to link all
jobs, results and device information to a specific device configuration.</p>
</dd>
<dt id="term-inline">inline<a class="headerlink" href="#term-inline" title="Permalink to this term">¶</a></dt><dd><p>A type of test definition which is contained within the job submission
instead of being fetched from a URL. These are useful for debugging tests
and are recommended for the synchronization support within
<a class="reference internal" href="#term-MultiNode"><span class="xref std std-term">MultiNode</span></a> test jobs.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="writing-tests.html#inline-test-definitions"><span class="std std-ref">Using inline test definitions</span></a></p>
</div>
</dd>
<dt id="term-interface-tag">interface tag<a class="headerlink" href="#term-interface-tag" title="Permalink to this term">¶</a></dt><dd><p>An interface tag is similar to <a class="reference internal" href="#term-device-tag"><span class="xref std std-term">device tag</span></a> but operate <strong>solely</strong>
within the <a class="reference internal" href="#term-VLANd"><span class="xref std std-term">VLANd</span></a> support. An interface tag may be related to the
link speed which is achievable on a particular switch and port - it may
also embed information about that link.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="vland.html#vland-device-tags"><span class="std std-ref">VLANd and interface tags in LAVA</span></a>.</p>
</div>
</dd>
<dt id="term-jinja2">jinja2<a class="headerlink" href="#term-jinja2" title="Permalink to this term">¶</a></dt><dd><p>Jinja2 is a templating language for Python, modelled after Django’s
templates. It is used in LAVA for device-type configuration, as it allows
conditional logic and variable substitution when generating device
configuration for the dispatcher.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference external" href="http://jinja.pocoo.org/docs/dev/">http://jinja.pocoo.org/docs/dev/</a></p>
</div>
</dd>
<dt id="term-job-context">job context<a class="headerlink" href="#term-job-context" title="Permalink to this term">¶</a></dt><dd><p>Test job definitions can include the <code class="docutils literal notranslate"><span class="pre">context:</span></code> dictionary at the top
level. This is used to set values for selected variables in the device
configuration, subject to the administrator settings for the device
templates and device dictionary. A common <a class="reference internal" href="explain_first_job.html#explain-first-job"><span class="std std-ref">example</span></a> is to instruct the template to use the
<code class="docutils literal notranslate"><span class="pre">qemu-system-x86_64</span></code> executable when starting a QEMU test job using the
value <code class="docutils literal notranslate"><span class="pre">arch:</span> <span class="pre">amd64</span></code>. All device types support variables in the job
context.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="qemu_options.html#override-variables-context"><span class="std std-ref">How to override variables</span></a> and
<a class="reference internal" href="writing-multinode.html#multinode-roles"><span class="std std-ref">Defining MultiNode roles</span></a></p>
</div>
</dd>
<dt id="term-job-definition">job definition<a class="headerlink" href="#term-job-definition" title="Permalink to this term">¶</a></dt><dd><p>The original YAML submitted to create a job in LAVA is retained in the
database and can be viewed directly from the job log. Although the YAML is
the same, the YAML may well have changed since the job was submitted, so
some care is required when modifying job definitions from old jobs to make
a new submission. If the job was a <a class="reference internal" href="#term-MultiNode"><span class="xref std std-term">MultiNode</span></a> job, the MultiNode
definition will be the unchanged YAML from the original submission; the job
definition will be the parsed YAML for this particular device within the
MultiNode job.</p>
</dd>
<dt id="term-LAVA_LXC_HOME">LAVA_LXC_HOME<a class="headerlink" href="#term-LAVA_LXC_HOME" title="Permalink to this term">¶</a></dt><dd><p>The path within <a class="reference internal" href="#term-LXC"><span class="xref std std-term">LXC</span></a> set to <code class="docutils literal notranslate"><span class="pre">/lava-lxc</span></code> by default. From the host
machine this path would be something like
<code class="docutils literal notranslate"><span class="pre">/var/lib/lxc/{container-name}/rootfs/lava-lxc</span></code>. Any files downloaded by
<a class="reference internal" href="actions-deploy.html#deploy-to-download"><span class="std std-ref">to: download</span></a> will be copied to this location which can then be
accessible from within the container.</p>
</dd>
<dt id="term-LXC">LXC<a class="headerlink" href="#term-LXC" title="Permalink to this term">¶</a></dt><dd><p><a class="reference external" href="https://en.wikipedia.org/wiki/LXC">Linux containers</a> are used in LAVA to
allow custom configurations on the dispatcher for each use. The extra
utilities or services are transparently available to the pipeline code and
selected device nodes can also be made available, depending on admin
configuration of the devices.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="deploy-lxc.html#deploy-using-lxc"><span class="std std-ref">Deploying test images using LXC</span></a>, <a class="reference internal" href="admin-lxc-deploy.html#lxc-deploy"><span class="std std-ref">Deploying LXC devices</span></a>,
<a class="reference internal" href="deploy-lxc.html#feedback-using-lxc"><span class="std std-ref">Feedback from the device</span></a> and <a class="reference internal" href="actions-protocols.html#lxc-protocol-reference"><span class="std std-ref">LXC protocol</span></a></p>
</div>
</dd>
<dt id="term-lxc">lxc://<a class="headerlink" href="#term-lxc" title="Permalink to this term">¶</a></dt><dd><p>This is a URL scheme specific to LAVA which points to files available in
<a class="reference internal" href="#term-LAVA_LXC_HOME"><span class="xref std std-term">LAVA_LXC_HOME</span></a>. An URL like <code class="docutils literal notranslate"><span class="pre">lxc:///boot.img</span></code> will refer to
<code class="docutils literal notranslate"><span class="pre">/var/lib/lxc/{container-name}/rootfs/lava-lxc/boot.img</span></code> on the host or
<code class="docutils literal notranslate"><span class="pre">/lava-lxc/boot.img</span></code> within the <a class="reference internal" href="#term-LXC"><span class="xref std std-term">LXC</span></a>. This URL scheme is valid
only when <a class="reference internal" href="actions-protocols.html#lxc-protocol-reference"><span class="std std-ref">LXC protocol</span></a> is defined in the test job. It also
only makes sense for the <code class="docutils literal notranslate"><span class="pre">deploy</span></code> and <code class="docutils literal notranslate"><span class="pre">boot</span></code> actions.</p>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>Pay attention to 3 forward slashes in the URL when referring to a
file.</p>
</div>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="actions-deploy.html#deploy-to-download"><span class="std std-ref">to: download</span></a></p>
</div>
</dd>
<dt id="term-messageID">messageID<a class="headerlink" href="#term-messageID" title="Permalink to this term">¶</a></dt><dd><p>Each message sent using the <a class="reference internal" href="multinodeapi.html#multinode-api"><span class="std std-ref">MultiNode API</span></a> uses a <code class="docutils literal notranslate"><span class="pre">messageID</span></code> which
is a string, unique within the group. It is recommended to make these
strings descriptive (use underscores instead of spaces). The messageID will
be included the the log files of the test.</p>
</dd>
<dt id="term-metadata">metadata<a class="headerlink" href="#term-metadata" title="Permalink to this term">¶</a></dt><dd><p>Test jobs should include metadata relating to the files used within the
job. Metadata consists of a key and a value, there is no limit to the
number of key value pairs as long as each key is unique within the metadata
for that test job.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="standard-test-jobs.html#job-metadata"><span class="std std-ref">Metadata</span></a></p>
</div>
</dd>
<dt id="term-MultiNode">MultiNode<a class="headerlink" href="#term-MultiNode" title="Permalink to this term">¶</a></dt><dd><p>A single test job which runs across multiple devices, or using
multiple independent connections to the same device.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="multinodeapi.html#multinode-api"><span class="std std-ref">MultiNode API</span></a>.</p>
</div>
</dd>
<dt id="term-namespace">namespace<a class="headerlink" href="#term-namespace" title="Permalink to this term">¶</a></dt><dd><p>A simple text label which is used to tie related actions together within a
test job submission where multiple deploy, boot or test actions are
defined. A common use case for namespaces is the use of <a class="reference internal" href="#term-LXC"><span class="xref std std-term">LXC</span></a> in a
test job where some actions are to be executed inside the LXC and some on
the <a class="reference internal" href="#term-DUT"><span class="xref std std-term">DUT</span></a>. The namespace is used to store the temporary locations of
files and other dynamic data during the running of the test job so that,
for example, the test runner is able to execute the correct test definition
YAML. Namespaces are set in the test job submission.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="#term-protocol"><span class="xref std std-term">protocol in the glossary</span></a>,
<a class="reference internal" href="deploy-lxc.html#namespaces-with-lxc"><span class="std std-ref">Namespaces</span></a>, <a class="reference internal" href="deploy-lxc.html#deploy-using-lxc"><span class="std std-ref">Deploying test images using LXC</span></a> and
<a class="reference internal" href="deploy-lxc.html#lava-lxc-protocol-android"><span class="std std-ref">Using the LXC protocol to support Android</span></a></p>
</div>
</dd>
<dt id="term-offline">offline<a class="headerlink" href="#term-offline" title="Permalink to this term">¶</a></dt><dd><p>A status of a device which allows jobs to be submitted and reserved for the
device but where the jobs will not start to run until the device is online.
Devices enter the offline state when a health check fails on that device or
the administrator puts the device offline.</p>
</dd>
<dt id="term-parameters">parameters<a class="headerlink" href="#term-parameters" title="Permalink to this term">¶</a></dt><dd><p>Parameters are used in a number of contexts in LAVA.</p>
<ul class="simple">
<li><p>For the use of parameters to control test jobs see
<a class="reference internal" href="writing-tests.html#test-action-parameters"><span class="std std-ref">Test shell parameters</span></a> and <a class="reference internal" href="simple-admin.html#overriding-constants"><span class="std std-ref">Overriding device constants</span></a>.</p></li>
<li><p>For the use of parameters within the codebase of the pipeline, see
<a class="reference internal" href="development-intro.html#developer-guide"><span class="std std-ref">Guide to development within LAVA</span></a> and <a class="reference internal" href="naming-conventions.html#naming-conventions"><span class="std std-ref">Naming conventions and LAVA architecture</span></a>.</p></li>
</ul>
</dd>
<dt id="term-PDU">PDU<a class="headerlink" href="#term-PDU" title="Permalink to this term">¶</a></dt><dd><p>PDU is an abbreviation for Power Distribution Unit - a network-controlled
set of relays which allow the power to the devices to be turned off and on
remotely. Many PDUs are supported by <code class="docutils literal notranslate"><span class="pre">pdudaemon</span></code> to be able to
hard reset devices in LAVA.</p>
</dd>
<dt id="term-physical-access">physical access<a class="headerlink" href="#term-physical-access" title="Permalink to this term">¶</a></dt><dd><p>The user or group with physical access to the device, for example to fix a
broken SD card or check for possible problems with physical connections.
The user or group with physical access is recommended to be one of the
superusers.</p>
</dd>
<dt id="term-pipeline">pipeline<a class="headerlink" href="#term-pipeline" title="Permalink to this term">¶</a></dt><dd><p>Within LAVA, the <code class="docutils literal notranslate"><span class="pre">pipeline</span></code> is the V2 model for the dispatcher code where
submitted jobs are converted to a pipeline of discrete actions - each
pipeline is specific to the structure of that submission and the entire
pipeline is validated before the job starts. The model integrates concepts
like fail-early, error identification, avoid defaults, fail and diagnose
later, as well as giving test writers more rope to make LAVA more
transparent. See <a class="reference internal" href="dispatcher-design.html#dispatcher-design"><span class="std std-ref">Lava Dispatcher Design</span></a> and <a class="reference internal" href="pipeline-usecases.html#pipeline-use-cases"><span class="std std-ref">Advanced Use Cases</span></a>.</p>
</dd>
<dt id="term-priority">priority<a class="headerlink" href="#term-priority" title="Permalink to this term">¶</a></dt><dd><p>A job has a default priority of <code class="docutils literal notranslate"><span class="pre">Medium</span></code>. This means that the job will be
scheduled according to the submit time of the job, in a list of jobs of the
same priority. Every <a class="reference internal" href="#term-health-check"><span class="xref std std-term">health check</span></a> has a higher priority than any
submitted job and if a health check is required, it will <strong>always</strong> run
before any other jobs. Priority only has any effect while the job is queued
as <code class="docutils literal notranslate"><span class="pre">Submitted</span></code>.</p>
</dd>
<dt id="term-production-image">production image<a class="headerlink" href="#term-production-image" title="Permalink to this term">¶</a></dt><dd><p>A build of Android which, when deployed to a device, means that the device is
<strong>not</strong> visible to <code class="docutils literal notranslate"><span class="pre">adb</span></code>. This is typically how a device is configured when
first sold to the consumer.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="deploy-lxc.html#lava-lxc-protocol-android"><span class="std std-ref">Using the LXC protocol to support Android</span></a></p>
</div>
</dd>
<dt id="term-prompts">prompts<a class="headerlink" href="#term-prompts" title="Permalink to this term">¶</a></dt><dd><p>A list of prompt strings which the test writer needs to specify in advance
and which LAVA will use to determine whether the boot was successful. One of
the specified prompts <strong>must</strong> match before the test can be started.</p>
</dd>
<dt id="term-protocol">protocol<a class="headerlink" href="#term-protocol" title="Permalink to this term">¶</a></dt><dd><p>A protocol in LAVA is a method of interacting with external services using
an <abbr title="Application Programming Interface">API</abbr> instead of with direct
shell commands or via a test shell. Examples of services in LAVA which use
protocols include <a class="reference internal" href="#term-LXC"><span class="xref std std-term">LXC</span></a>, <a class="reference internal" href="#term-MultiNode"><span class="xref std std-term">MultiNode</span></a> and <a class="reference internal" href="#term-VLANd"><span class="xref std std-term">VLANd</span></a>. The
protocol defines which API calls are available through the LAVA interface
and the Pipeline determines when the API call is made.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="actions-protocols.html#protocols"><span class="std std-ref">Protocol Reference</span></a></p>
</div>
</dd>
<dt id="term-query">query<a class="headerlink" href="#term-query" title="Permalink to this term">¶</a></dt><dd><p>See <a class="reference internal" href="lava-queries-charts.html#result-queries"><span class="std std-ref">Using Test Results</span></a>. Queries are used to identify test jobs and
associated results which match specified criteria based on the results or
metadata.</p>
</dd>
<dt id="term-refactoring">refactoring<a class="headerlink" href="#term-refactoring" title="Permalink to this term">¶</a></dt><dd><p>Within LAVA, the process of developing the <a class="reference internal" href="#term-pipeline"><span class="xref std std-term">pipeline</span></a> code in
parallel with the existing code, resulting in new elements alongside old
code - possibly disabled on some instances. See <a class="reference internal" href="dispatcher-design.html#dispatcher-design"><span class="std std-ref">Lava Dispatcher Design</span></a>
and <a class="reference internal" href="pipeline-usecases.html#pipeline-use-cases"><span class="std std-ref">Advanced Use Cases</span></a>.</p>
</dd>
<dt id="term-remote-worker">remote worker<a class="headerlink" href="#term-remote-worker" title="Permalink to this term">¶</a></dt><dd><p>A dispatcher with devices attached which does not have a web frontend but
which uses an HTTP connection to a remote lava-server to control the
operation of test jobs on the attached devices.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="growing_your_lab.html#growing-your-lab"><span class="std std-ref">Growing your lab</span></a></p>
</div>
</dd>
<dt id="term-restricted-device">restricted device<a class="headerlink" href="#term-restricted-device" title="Permalink to this term">¶</a></dt><dd><p>A restricted device can only accept job submissions from the device owner.
If the device owner is a group, all users in that group can submit jobs to
the device.</p>
</dd>
<dt id="term-results">results<a class="headerlink" href="#term-results" title="Permalink to this term">¶</a></dt><dd><p>LAVA results provide a generic view of how the tests performed within a
test job. Results from test jobs provide support for <a class="reference internal" href="#term-query"><span class="xref std std-term">queries</span></a>, <a class="reference internal" href="#term-chart"><span class="xref std std-term">charts</span></a> and <a class="reference internal" href="first-job.html#downloading-results"><span class="std std-ref">downloading results</span></a> to support later analysis and <a class="reference internal" href="#term-frontend"><span class="xref std std-term">frontends</span></a>. Results can be viewed whilst the test job is running. Results
are also generated during the operation of the test job outside the test
action itself. All results are referenced solely using the test job ID.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="writing-tests.html#recording-test-results"><span class="std std-ref">Recording test case results</span></a>, <a class="reference internal" href="custom-result-handling.html#custom-result-handling"><span class="std std-ref">Custom result handling</span></a> and
<a class="reference internal" href="first-job.html#viewing-results"><span class="std std-ref">Viewing test results</span></a>.</p>
</div>
</dd>
<dt id="term-retired">retired<a class="headerlink" href="#term-retired" title="Permalink to this term">¶</a></dt><dd><p>A device is retired when it can no longer be used by LAVA. A retired device
allows historical data to be retained in the database, including log files,
result bundles and state transitions. Devices can also be retired when the
device is moved from one instance to another.</p>
</dd>
<dt id="term-role">role<a class="headerlink" href="#term-role" title="Permalink to this term">¶</a></dt><dd><p>An arbitrary label used in MultiNode tests to determine which tests are run
on the devices and inside the YAML to determine how the devices
communicate.</p>
</dd>
<dt id="term-rootfs">rootfs<a class="headerlink" href="#term-rootfs" title="Permalink to this term">¶</a></dt><dd><p>A tarball for the root file system.</p>
</dd>
<dt id="term-rootfstype">rootfstype<a class="headerlink" href="#term-rootfstype" title="Permalink to this term">¶</a></dt><dd><p>Filesystem type for the root filesystem, e.g. ext2, ext3, ext4.</p>
</dd>
<dt id="term-scheduler">scheduler<a class="headerlink" href="#term-scheduler" title="Permalink to this term">¶</a></dt><dd><p>There is a single scheduler in LAVA, running on the server. The
scheduler is responsible for assigning devices to submitted test jobs.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="index.html#scheduling"><span class="std std-ref">Scheduling</span></a></p>
</div>
</dd>
<dt id="term-target_group">target_group<a class="headerlink" href="#term-target_group" title="Permalink to this term">¶</a></dt><dd><p>In <a class="reference internal" href="#term-MultiNode"><span class="xref std std-term">MultiNode</span></a>, the single submission is split into multiple test
jobs which all share a single <code class="docutils literal notranslate"><span class="pre">target_group</span></code> which uses a string as a
unique ID. The <code class="docutils literal notranslate"><span class="pre">target_group</span></code> is usually transparent to test writers but
underpins how the rest of the MultiNode API operates.</p>
</dd>
<dt id="term-test-case">test case<a class="headerlink" href="#term-test-case" title="Permalink to this term">¶</a></dt><dd><p>An individual test case records a single test event as a pass or fail
along with measurements, units or a reference.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="results-intro.html#results-intro"><span class="std std-ref">Introduction to Results in LAVA</span></a></p>
</div>
</dd>
<dt id="term-test-run">test run<a class="headerlink" href="#term-test-run" title="Permalink to this term">¶</a></dt><dd><p>The result from a single test definition execution. The individual id and
result of a single test within a test run is called the <a class="reference internal" href="#term-test-case"><span class="xref std std-term">Test Case</span></a>.</p>
</dd>
<dt id="term-test-shell">test shell<a class="headerlink" href="#term-test-shell" title="Permalink to this term">¶</a></dt><dd><p>Most test jobs will boot into a POSIX type shell, much like if the user had
used <code class="docutils literal notranslate"><span class="pre">ssh</span></code>. LAVA uses the test shell to execute the tests defined in the
Lava Test Shell Definition(s) specified in the job definition.</p>
</dd>
<dt id="term-test-set">test set<a class="headerlink" href="#term-test-set" title="Permalink to this term">¶</a></dt><dd><p>Test writers can choose to subdivide a single <a class="reference internal" href="#term-test-suite"><span class="xref std std-term">test suite</span></a> into
multiple sets, for example to handle repetition or changes to the
parameters used to run the tests.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="results-intro.html#test-set-results"><span class="std std-ref">Test Set</span></a></p>
</div>
</dd>
<dt id="term-test-suite">test suite<a class="headerlink" href="#term-test-suite" title="Permalink to this term">¶</a></dt><dd><p>Individual test cases are aggregated into a test suite and given the name
specified in the test job definition. The Test Suite is created when
results are generated in the running test job. LAVA uses a reserved test
suite called <code class="docutils literal notranslate"><span class="pre">lava</span></code> for results generated by the actions running the test
job itself. Results in the <code class="docutils literal notranslate"><span class="pre">lava</span></code> suite contain details like the commit
hash of the test definitions, messages from exceptions raised if the job
ends Incomplete and other data about how the test behaved.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="results-intro.html#results-test-suite"><span class="std std-ref">Test Suite</span></a></p>
</div>
</dd>
<dt id="term-tftp">tftp<a class="headerlink" href="#term-tftp" title="Permalink to this term">¶</a></dt><dd><p>Trivial File Transfer Protocol (TFTP) is a file transfer protocol, mainly
to serve boot images over the network to other machines (e.g. for PXE
booting). The protocol is managed by the <a class="reference external" href="https://tracker.debian.org/pkg/tftp-hpa">tftpd-hpa package</a> and <strong>not</strong> by LAVA directly.</p>
</dd>
<dt id="term-token">token<a class="headerlink" href="#term-token" title="Permalink to this term">¶</a></dt><dd><p>LAVA uses tokens to authenticate users via the <a class="reference internal" href="data-export.html#xml-rpc"><span class="std std-ref">XML-RPC</span></a> and REST APIs.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="first_steps.html#authentication-tokens"><span class="std std-ref">Authentication Tokens</span></a></p>
</div>
</dd>
<dt id="term-UART">UART<a class="headerlink" href="#term-UART" title="Permalink to this term">¶</a></dt><dd><p>A <abbr title="Universal asynchronous receiver-transmitter">UART</abbr> is the most
common way to make a serial connection to a <a class="reference internal" href="#term-DUT"><span class="xref std std-term">DUT</span></a>. Some devices can
support multiple UARTs. This can be useful as a way to isolate the test
shell processing from kernel messages.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference external" href="https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter">UART article on Wikipedia</a>
and <a class="reference internal" href="connections.html#multiple-serial-support"><span class="std std-ref">Multiple serial port support</span></a>.</p>
</div>
</dd>
<dt id="term-visibility">visibility<a class="headerlink" href="#term-visibility" title="Permalink to this term">¶</a></dt><dd><p>Supports values of <code class="docutils literal notranslate"><span class="pre">public</span></code>, <code class="docutils literal notranslate"><span class="pre">personal</span></code> and <code class="docutils literal notranslate"><span class="pre">group</span></code> and
controls who is allowed to view the job and the results generated
by the job. This includes whether the results are available to
queries and to charts:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">visibility</span><span class="p">:</span> <span class="n">personal</span>
</pre></div>
</div>
<p>or:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">visibility</span><span class="p">:</span> <span class="n">public</span>
</pre></div>
</div>
<p><code class="docutils literal notranslate"><span class="pre">group</span></code> visibility setting should list the groups users must be
in to be allowed to see the job. If more than one <a class="reference internal" href="#term-group"><span class="xref std std-term">group</span></a> is
listed, users must be in all the listed groups to be able to view
the job or the results:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">visibility</span><span class="p">:</span>
  <span class="n">group</span><span class="p">:</span>
    <span class="o">-</span> <span class="n">developers</span>
    <span class="o">-</span> <span class="n">project</span>
</pre></div>
</div>
<p>In this example, users must be members of both <code class="docutils literal notranslate"><span class="pre">developers</span></code> group
and <code class="docutils literal notranslate"><span class="pre">project</span></code> group. Groups must already exist in the Django
configuration for the instance.</p>
</dd>
<dt id="term-VLANd">VLANd<a class="headerlink" href="#term-VLANd" title="Permalink to this term">¶</a></dt><dd><p>VLANd is a daemon to support virtual local area networks in LAVA. This
support is specialized and requires careful configuration of the entire
LAVA instance, including the physical layout of the switches and the
devices of that instance.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p><a class="reference internal" href="vland.html#vland-in-lava"><span class="std std-ref">VLANd support in LAVA test jobs</span></a> or <a class="reference internal" href="vland-admin.html#admin-vland-lava"><span class="std std-ref">Administering VLANd support in LAVA</span></a>.</p>
</div>
</dd>
<dt id="term-worker">worker<a class="headerlink" href="#term-worker" title="Permalink to this term">¶</a></dt><dd><p>The worker is responsible for running the <code class="docutils literal notranslate"><span class="pre">lava-worker</span></code> daemon to start
and monitor test jobs running on the dispatcher. Each server has a
worker installed by default. When a dispatcher is added to the master as a
separate machine, this worker is a <a class="reference internal" href="#term-remote-worker"><span class="xref std std-term">remote worker</span></a>. The admin decides
how many devices to assign to which worker. In large instances, it is
common for all devices to be assigned to remote workers to manage the load
on the master.</p>
</dd>
</dl>
</section>


    </div>
      
  </div>
</div>
<footer class="footer">
  <div class="container">
    <p class="pull-right">
      <a href="#">Back to top</a>
      
    </p>
    <p>
        &copy; Copyright 2010-2019, Linaro Limited.<br/>
      Created using <a href="http://sphinx-doc.org/">Sphinx</a> 5.3.0.<br/>
    </p>
  </div>
</footer>
  </body>
</html>